PD ROM 1/PD ROM Volume I - Macintosh Software from BMUG (1988).iso/Electronic Messages/USEnet Digests/USEnet Vol. 4/USEnet 4.67

Text File | 1988-06-18 | 44.4 KB | 1,072 lines | [TEXT/ttxt]

List (Unformatted): USENET MAC DIGEST V4 #67


Usenet Mac Digest     Friday, May 20, 1988           Volume 4 : Issue 67

Today's Topics:
     Re: Prob with LaserWriter II NTX and font disk
     MAC to VAX/VMS Connection info wanted
     need help with font files
     Viruses and Tamper-Proof Packaging
     Re: What's the best NETWORK?
     Utilities for RGB to 8-Bit
     Re: Prob with LaserWriter II NTX and font disk
     Math Word Processing
     Re: X-Windows on the Mac
     Re: Brief overview of FullWrite (Re
     Re: MAC to VAX/VMS Connection info wanted
     Building a SCSI disk (Long Summary)
     Re: Getting started in Mac programming...
     Re: Writing PICT files
     Anyone using pcl (clos) under Allegro Common Lisp?
     "Asynchronous" processing in Allegro Common Lisp?
     Re: Anyone using pcl (clos) under Allegro Common Lisp? (2 messages)
     Re: suppress display of password entry
     Re: Utilities for RGB to 8-Bit

----------------------------------------------------------------------

From: [e-mail] (0000;0000015000;4000;250;216;ecs165s)
Subject: Re: Prob with LaserWriter II NTX and font disk
Date: 19 May 88 01:04:12 GMT
Organization: University of California, Davis

I've used an Everex EMAC-20 as a font disk for about a month now with no
problems.  Just use the LaserWriter Font Utility to initialize the disk
and away you go!
--
----------------------------------------------------------------
Registrar:
    from the latin "registrarum" meaning "screw the student"
----------------------------------------------------------------
Greg DeMichillie               |{ucbvax, lll-crg, sdcsvax}
[e-mail]      |      !ucdavis!lgdemichillie
or [e-mail]      |
AppleLink : ST0178             |
----------------------------------------------------------------


------------------------------

From: [e-mail] (baby!!)
Subject: MAC to VAX/VMS Connection info wanted
Date: 17 May 88 10:20:17 GMT
Organization: Department of Computing at Lancaster University, UK.

Ho hum, here we go again,.....
        I'm looking for information relating to the connection of appletalk
networks with lots of Mac's on, to DECNET over ethernet with lots of
VAX/MicroVAX on. What I need to know is -

        a) Whats availaible for connecting the two networks together

        b) What software packages run on the two types of machines that allow
           file transfer/sharing, mail, virtual disk, etc etc, etc.....

About the only info I do have at the moment is some scant comments on
the kinetics fastpath bridge....so I'm looking for anything and
everything.

I know this is rather a broad request, and no doubt it'll turn up in
news groups where its not wanted, apologies in advance etc and cheers
for any help, mail me with any info, try not to clutter up the groups,
if I get enough info I'll summerise and post as is the custom.

cheers rodge....

Mac/VAX/MicroVAX/Fastpath etc etc are probably all trademarks of
somebody.
--
-------------------------------------------------------------------------------
janet:  [e-mail]           Department of Computing
arpa:   [e-mail]           University of Lancaster
uucp:   ...!mcvax!ukc!dcl-cs!rodger       Bailrigg, Lancaster, LA1 4YR, UK


------------------------------

From: [e-mail]
Subject: need help with font files
Date: 19 May 88 05:19:24 GMT

I'm trying to read font/da mover files on unix with a C program that I
am writing.  IM vol. I isn't as clear as I'd wish.  Does anybody have
any C code that reads and displays a mac font file? I'm currently stuck
on getting the bit images out of the bitImage array in the FontRec.
Please mail it to me; I don't read this newsgroup.  Thanks.

--------------------------------------
        rusty c. wright
        [e-mail] ucbvax!cartan!rusty


------------------------------

From: [e-mail]
Subject: Viruses and Tamper-Proof Packaging
Date: 19 May 88 15:57:46 GMT
Organization: (none)

>From: Stanley Letovsky <letovsky-stanley>

Re:   Atul Butte's proposal for "tamper-proof packaging" for software to
prevent dissemination of software viruses (Comp.sys.mac Sun, 08 May 88):

      Butte proposes a variation on the one-way encryption functions of
public key cryptography schemes which could encrypt software in a way
that ensures that the software actually came straight from the vendor.
He also suggests that the decryption key could somehow be provided along
with the encrypted software.  His proposal is interesting, and seems
viable in its overall framework, but one detail is problematic.  One
cannot distribute the decryption key with the encrypted software:  any
evil hacker could create such a package, encrypting virus-infected
software and supplying his own key.  The decryption keys must be
publicly posted in such a way that the consumer could have absolute
confidence that they belong to a reputable firm, while the firm is
responsible for ensuring that they alone know how to encrypt for their
publicly posted decryption key.

      Incidentally, Butte's scheme would seem to have implications for
preventing software bootlegging.  The vendor could supply the decryption
key only to customers with proof of purchase.  Bootleggers would have to
risk virus infection.  Vendors might even be motivated to distribute
infected bootleg copies around the marketplace, so as to heighten demand
for the genuine article.  Of course, they could do that even without
tamper-proof packaging...

                        Stan Letovsky    [e-mail]
                        David Littman    [e-mail]



------------------------------

From: [e-mail] (Paul Steele)
Subject: Re: What's the best NETWORK?
Date: 18 May 88 11:58:59 GMT
Organization: School of Computer Science, Acadia Univ., Nova Scotia

I just saw a demo of MacJANET 2.0 at the Apple Educational Symposium.
This new version has several improvements, such as multiple (named) file
servers, better print spooling and control of print jobs, program usage
restriction, program quotas, software encryption (which makes piracy
VERY difficult), and a much improved administration program.  Waterloo
has done a good job on this new release.  Now I just have to wait for
our copy.

Incidently, Waterloo is setting up a new Macintosh lab consisting of 60
Mac II's networked using ethernet.  I sure wish we had that kind of
money!

--
Paul H. Steele      USENET:   {uunet|watmath|utai|garfield}!dalcs!aucs!Paul
Acadia University   BITNET:   Paul@Acadia
Wolfville, NS       Internet: [e-mail]
CANADA  B0P 1X0     [phone]x587


------------------------------

From: [e-mail] (Richard Rosenthal)
Subject: Utilities for RGB to 8-Bit
Date: 19 May 88 12:04:11 GMT
Organization: USAETL, Fort Belvoir, Virginia


        I have a 24-bit color image on VAX with UNIX:
            8-bit red
            8-bit green
            8-bit blue

        I want to display this on Mac II, 8-bit video.

        Any suggestions?

--
Richard Rosenthal                            | ARPANET:  [e-mail]
US Army Engineer Topographic Laboratories    | UUCP:     (use ARPANET)
Ft. Belvoir, VA 22060-5546                   | PHONE:    [phone]


------------------------------

From: [e-mail] (ephraim vishniac)
Subject: Re: Prob with LaserWriter II NTX and font disk
Date: 19 May 88 12:52:53 GMT
Organization: Thinking Machines Corporation, Cambridge, MA

>2. It must be able to report to the printer what size volume it is.
>   This is done via the SCSI command "Mode Select".

Mode Select allows the host to *set* (i.e. select) various
characteristics of the drive.  Mode *Sense* is the command that allows
the host to retrieve the drive characteristics.  This is probably the
command that Jim Kateley's thinking of.

Mode Sense is a tough way to get the size of the drive, though.  Read
Capacity is much easier since it simply returns the sector size and last
sector number, with no other junk to parse.
--
Ephraim Vishniac                                          [e-mail]
Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142-1214

     On two occasions I have been asked, "Pray, Mr. Babbage, if you put
     into the machine wrong figures, will the right answers come out?"


------------------------------

From: [e-mail] (Alan Day)
Subject: Math Word Processing
Date: 18 May 88 06:00:44 GMT
Organization: Lakehead University; Thunder Bay, Ont


I would like to reiterate some points discussed in earlier submissions
on Math typesetting for the Mac. Hopefully FullWrite and/or Nissus (even
Word?) might include these in future releases.

Aside from display equations (which a DA can handle well enough),  a
mathematician needs to imbed limited symbol constructs in paragraph
text. To do this, two features already implemented in LaserAuthor (the
only good things in that programme) should not be that hard to put into
any other WP programme.

        (1) multiple (adjustable?) levels of sub- and super-scripts. The
adjustment might be necessary if the default settings are not correct as
in Word. (Anyone know how to FEdit these values for Word? The
workarounds that I know are very time consuming and unnatural.)

        (2) Intuitive CHARACTER overstrike capability (LaserAuthor used
COMMAND-backspace between the characters). This would allow writing e.g.
NOT less than, and x sub i super j in paragraph text easily.

        (3) a general wish would be macros and command-key assignment (which
means the programme must not gobble up all possible assignments for
obscure power user capabilities. Are you listening Word?)

Does anyone know of a WP package with these minor :-) abilities?

        Alan Day


------------------------------

From: [e-mail] (Dan Magorian)
Subject: Re: X-Windows on the Mac
Date: 19 May 88 20:08:53 GMT
Organization: University of Maryland, College Park

White Pine Software (94 Route 101A, PO Box 1108, Amherst NH 03031) has
announced a product called Mercury that is supposed to be an X Window
server for the Mac OS.  It's not out yet even in beta, you can call them
for the brochure. [phone] (This isn't an ad, I'm quoting from
their brochure - we hope to beta test it here when it's ready).


------------------------------

From: [e-mail] (Chuq Von Rospach)
Subject: Re: Brief overview of FullWrite (Re
Date: 19 May 88 16:27:02 GMT
Organization: Fictional Reality

>general are failures also?   I don't think so.  People who can't understand
>why we need WYSWYG are failures, and personally I like to be able to see
>what my work is going to look like while I'm working on it.

I think this is being overly harsh. I'm a BIG fan of WYSIWYG. But I'm
also a hardcore writer who types 100WPM or so. And when I'm writing, I
dont' want to edit, I don't want to format, and I don't want to make it
pretty. All my work goes through at least three phases: getting the
damned words into the system, getting the damned words spelled write and
getting the damned words looking right and back out of the system.

The problem with most WYSIWYG systems is that they are designed with
doing all three at the same time, and fight anyone who just wants to
dump words into the system at the greatest possible speed with the
fewest interruptions. This is very true of FullWrite, for instance.
Microsoft Word's one great advantage is that when I just want to write,
it'll sit back and stay out of the way -- although they to some degree
go too far in that direction and make it hard tweak the words with that
ugly user interface of theirs.

If there was one thing I'd really like to see in FWP in a future
release, it is a "Turn off the repagination and WYSIWYG" mode. The
delays it tosses at me when I cross a page boundary ("Oh! Page boundary!
Draw a new page! move the text! put up the header! scroll the screen!
Okay, you can write again now") can be very distracting if they hit at
the wrong time -- writing is hard enough work without having the word
processor arguing with you. Another thing I'd like to be able to turn
off is FWP's insistence on showing the entire page of blank paper when
you have things like pictures that shift to the next page. I'd love to
be able to scrunch that page down to just the size necessary to show
what's on it -- the WYSIWYG setup is nice enough that I can still tell
where the beginning and ending of the page are, which is Good Enough.

(and if this sounds like Griping, well, yes, it is. Bul I'll be damned
if I go back to Word 3.0, and I'm already finding that I'm retraining my
writing habits to take FWP's quirks into account. Another couple of
weeks, and I probably won't be bothered at all by most of them, except
possibly subliminally. Just to put the griping into perspective....)

Chuq Von Rospach                        [e-mail]            Delphi: CHUQ

        Robert A. Heinlein: 1907-1988. He will never truly die as long as we
                           read his words and speak his name. Rest in
Peace.


------------------------------

From: [e-mail] (Jeff Shulman)
Subject: Re: MAC to VAX/VMS Connection info wanted
Date: 20 May 88 14:50:26 GMT
Organization: Schlumberger-Doll Research, Ridgefield CT

AlisaSystems (1-800-99-ALISA) has (at least) two products you might be
interested in:  AlisaShare and TSSNet.

AlisaShare (currently in beta test) turns any Vax into an AppleShare
server. I believe Alisa has recently licensed the AppleShare software to
go on the Macs.

TSSNet turns any Mac into a DECNET end node.  You need one copy for each
Mac.  You get mail, file transfer and DECNET terminal (through your
current terminal emulator).

TOPS is also coming out with a version of its software for VMS.  You
would need to have TOPS for each Mac you wanted to have VAX access.

Disclaimer: We are a beta test site for Alisa but I would recommend
their stuff anyway.  We are also beta testing VMS TOPS but haven't
received it yet (RSN).  Also, these are my personal opinions and do not
necessarily reflect the opinions of my employer.

                                                        Jeff
--
uucp:     ...rutgers!yale!slb-sdr!shulman
CSNet:    [e-mail]
Delphi:   JEFFS
GEnie:    KILROY
CIS:      76136,667
MCI Mail: KILROY


------------------------------

From: [e-mail] (Nasser Lone)
Subject: Building a SCSI disk (Long Summary)
Date: 18 May 88 23:53:48 GMT
Organization: Fortune Systems / SCI Technology  (Berkeley, CA)


Sometime ago, I posted a query about putting together a SCSI drive for
the Macintosh.  I have been working with SCSI drives on our UNIX box
where we have a generic SCSI driver.  This driver conforms to the SCSI
specifications and works with several different embedded SCSI drives.
SCSI is nice in that it provides a generic format command so that the
software does not have to worry about drive parameters such as number of
heads, number of cylinders, etc.  The only parameter that should be
provided is the block size.  There is also a read capacity command that
can be used to find out the number of blocks on the drive.  So, I
thought that it should be simple to do all this in the Mac world.

Based on what I have learned since my original posting, I still think
that it should not be too hard to write general software that would be
able to do all that is necessary, but it has not been done yet.  It
seems to me that most of what has been done has built-in dependencies,
so that the driver from one manufacturer will probably not work with a
drive from another.

One thing to remember is that the Macintosh operating system does not
include a driver for SCSI hard disks.  It includes a SCSI manager that
can be used to communicate with SCSI devices, but the driver itself is
placed on the drive from where it is loaded into the system at boot
time. So anybody trying to build a drive has to write this driver (or
modify an existing one).  Another piece of software needed is what is
referred to as the formatter-installer.  This software issues the
low-level format command to the drive, places the necessary information
in blocks 0 and 1 on the drive, and puts the driver on the drive.  Thus
the following steps take place in the process of building the drive:
        1.  Format the drive (through the SCSI format command).
        2.  Build block 0 (info about capacity, block size, driver, etc).
        3.  Build block 1 (disk partition info).
        4.  Place the driver on the disk.

There are many sources of help available.  I am listing below some that
I have come across or that I have been told about.
        -  Inside Macintosh Vol. IV -- chapter on SCSI.
        -  Macintosh Tech Note 96.
        -  Macintosh Tech Note 159 -- the purpose of this note seems to
           be to discourage people from building SCSI drives.  I think
it
           is too negative for people who know about SCSI.
        -  BMUG Fall 86 Newletter -- Building Your Own Hard Disk by Tim
           Standing.  I was told that the author did not finish his
           project.
        -  SCSI Tools disk from APDA (Apple Professional Developers
           Assoc.).  This disk contains a sample driver for the SCSI
           disk.
        -  The FS&I program from Ephraim Vishniac.  This shareware
           program will prepare the hard disk and write a driver to it.
           I used this program successfully on a drive; more on that
           later.
        -  Several people mentioned articles in MacTutor but I have not
           seen those.

In terms of hardware, one needs the following:
        1.  A case.
        2.  Power supply.  I have been told that one should use a
            switching power supply for this purpose.  Make sure that the
            power supply can provide enough juice for the drive (and
            controller if you are using one).
        3.  The drive.
        4.  A controller card if you are not using an embedded SCSI
            drive.
        5.  Cable from Mac DB25 port to Centronics 50-pin.  These are
            widely available in the Bay Area (Fry's, MAC in Berkeley).
        6.  Cable from 50-pin Centronics to 50-pin socket connector on
            the drive (easy to build one).

I have done some experimentation so far.  I hooked up a drive to the Mac
using some adhoc connectors and used Vishniac's FS&I program.  I was
able to format a drive and subsequently boot from it.  However, I could
not get the program to work with a CDC Wren III drive.  My co-worker was
told by Dave Platt at Coherent Thought that FS&I and CDC Wren III are
incompatible, something I do not understand.  To use the FS&I program,
you have to manipulate resources using ResEdit.  You also have to know
some things about the drive.  One complaint I had about the program is
that it does all steps of formatting and initializing in one sequence.
I think such a program should consist of three independent parts:
        -   Format and build block 0.
        -   Manipulate partition info.
        -   Place the driver on the disk. Also, it seems that the driver that
is part of this program does not support multiple-partitions.


Following are the responses that I got to my query.  My thanks to all
the people who took the time to help a fellow netter.


Nasser          ...!pacbell!forbrk!nasser

****************************************************************************

>From: sun!coherent!dplatt (Dave Platt)
Organization: Coherent Thought Inc., Palo Alto CA

I'd recommend looking in the back of any of the popular electronics
magazines, PC Shopper, and so forth... lots of ads for hardware, power
supplies, cases, and so forth.  The simplest approach (although neither
the cheapest nor the smallest) would be to buy a case and power-supply
designed for a PC-clone, and install the disk in it.

If you buy a disk and controller that matches one of the combinations
used by Apple, you could probably use HD SCSI Setup (or whatever it's
called) to format and drive the disk.

A more general approach would be to use Ephraim Vishniac's SCSI
Formatter and Installer package... it's shareware, includes two sample
drivers (one for blind I/O and one for synchronized I/O), and is very
flexible and easy to configure.  The shareware fee is a pint of blood,
donated to your local Red Cross (or a cash donation).  SCSI F&I is
available for anonymous FTP on SUMEX;  if you don't have FTP access and
can't find a copy locally, let me know and I'll arrange to get you a
copy.

Hacking a SCSI interface is not a task for the timid nor the unlearned!

Be warned that some drives (e.g. the newer CDC Wrens) will not work with
the Mac Plus SCSI port... the Plus has a relatively buggy
implementation.  There are some Apple tech notes relating to the SCSI
port on the Plus;  let me know if you'd like me to dig 'em up for you.

You may find that the cost of putting together an effective SCSI drive
may not be significantly less than the cost of buying a low-end drive of
similar capabilities... once you add in the single-unit cost of a case,
power supply, cable, and so forth.  Perhaps buying an external (or
internal) drive from an existing manufacturer would be a better
solution... only you can decide.

****************************************************************************

>From: Juri Munkki <lll-tis!lll-crg!uunet!santra.hut.fi!jmunkki>
Organization: Helsinki University of Technology, Finland

I recomment the Seagate ST277N. It is a 40 ms, 64 MB half height 5.25"
drive with a built-in intelligent SCSI controller. It is relatively
cheap.

Try the CMS software, if you don't mind using commercial software.
Ephraim Vishniac's generic SCSI also works, but it has some problems.
You might have to use Vishniac's formatter before the CMS formatter (I
don't know why this it is this way. The CMS 60 is an ST277N).

Get yourself the Apple SCSI developers package and all the MacTutor
back-issues that have SCSI drivers. It isn't nearly impossible to write
one from scratch. Using the MacTutor examples it might be almost easy.

****************************************************************************

>From: noao!naucse![e-mail] (Paul Balyoz)

Carl Nelson and Associates in Seattle Wa. ,now called Software
Architects, is selling their driver which several major hard drive
vendors sell under their own label. I think their looking for $50,  and
the installer software is very good. The address is:

****************************************************************************

>From: lll-tis!ames!im4u!rolex!twb (Tom Bereiter)

About your question on the net concerning SCSI disks:  Software-wise the
best thing you can do is to get hold of a copy of a shareware package
designed expressly for attaching alien disks.  It's called something
like "SCSI formatter" and is posted on the info-mac archives at
sumex.standford.edu. You just edit some templates with ResEdit and end
up with a custom formatter/ installer.  If you have trouble finding it
let me know and I'll post it to  the net--seeing as this question comes
up every few months.

****************************************************************************

>From: ames!lll-lcc!csustan!psivax.psi.siemens.COM!rabbit
Organization: Pacesetter Systems Inc., Sylmar, CA

I built my own with the following:
        MD01 Emulex SCSI controller (to ST506 drives)
        Maxtor 85 meg drive
        PC clone cabinet and power supply
        cables - Apple's SCSI cable (DB25 to 50 pin centronics)
                 50 pin centronics to 50 pin SCSI connector (I
                 forget what those are called; the 2 row of 25
                 pins on the controller) using flat ribbon cable

I used the Emulex controller because that was the one that I had on my
UNIX system before I got another hard disk with a built in controller.
The Emulex controller goes for $200 or so I think (not cheap) and can
handle 2 hard disks (though the software driver doesn't know how to use
it).  If I had to start from scratch, I'd probably get the Adaptec
controller for $100 or so.

The Maxtor drive I got went for around $900 which is about the going
price at that time (within the $10/meg that I was looking at anyways).

PC clone cabinet - $35 power supply - $65 (I think it was a 150 watt
supply; more than enough
        for the drive and controller; I'm not sure if a cheapie 65
        watt one would have worked but I'm possibly thinking of putting
        another drive in there)
        [at least there's one good thing about PC clones... cheap
         hardware; you can buy a single hard disk cabinet and power
         supply and it will cost more than the clone stuff; though
         the clone stuff is bigger than you'd need for bare bones;
         I just set my clone case on its side]

I'm currently trying to implement Apple's SCSI driver to work with my
system.  IM Vol 4 and 5 gives details of what's required. Also, MacTutor
had a few articles about how to do this.  Check the Jan 88 issue of
MacTutor for details on modifying Apple's driver.  There's also a few
public domain drivers out there but I don't know of any.  You should
also look at Apple's Tech notes on SCSI information if you're starting
from scratch.

****************************************************************************

>From: [e-mail] (John G. Haub)

Dear Nasser,

        It's good to see that I'm not the only fool contemplating such a
project. Here in Oz hard disks are still very expensive >= $A1500. So it
appears an attractive project.

        In my case I've probably narrowed my requirements down a little  but
still I would be very grateful to hear about any information that you
might receive. I intend using two Epson 20Mb winchesters, which I
understand are a  fairly generic hard disk although not one of the more
recognised brands such Segate (the reason being I got them at the right
price).

        I've read the Feb '87 Mactutor article 'build your own SCSI hard disk'
by Tim Standing and have spoken to a few people here in Oz and believe
that just about any SCSI controller will do however I'v been informed
that the real problem(s) is to develop software for formating the disk
and installing a SCSI driver which will work with the appropriate
controller. Tim published the software for the device that he built and
I have a copy of that software. So consequently I have been specifically
chasing the controller that he used. I've had very little luck here in
Oz locating such a board, the one piece of luck that I had proved to be
prohibitively expensive (~$500 A). A friend of  mine at Standford Uni
over your way has found that Wyle Labs sell the  appriate board for $156
US (much cheaper for me to import one) and he is still chasing round for
a lower price. The particular board that I am interested in is Adaptec
model ACB-4000A.

        As I said before, any information that you dig up would be greatly
appreciated down here in Oz.

****************************************************************************


------------------------------

From: [e-mail] (David M. O'Rourke)
Subject: Re: Getting started in Mac programming...
Date: 19 May 88 04:05:44 GMT
Organization: Cal Poly State University -- San Luis Obispo

In article <[e-mail]> [e-mail] (Guido van Rossum) writes:
>I'd like to make a comparison between LightspeedC (LSC) and MPW.

  Continues on with an EXCELLENT comparison of LSC vs. MPW.  One of the
best I've seen, listed some things I've never seen before.

>As far as I know, neither system has much debugging support beyonde
>generating symbols for Macsbug.

  I think one of the RUMORED features of MPW 3.0 will be souce level
debugging.

  The one thing Mr. van Rossum leaves out is the fact that MPW supports
more than just C, although C is the choice of many programmers there are
other languages, and MPW supports most of them.  Also I've found MPW to
be quite useable on a 2 meg machine with a 20meg harddisk.  And you
can't deny the power of it's Unix style shell and the ability to add
tools to the shell just like in Unix.

   Although LSC is fast, MPW is complete.

   I have also heard rumors that many of the Macintosh compiler
companies are planning versions of there compilers to run under MPW, so
you not only have a choice of languages you *MIGHT* soon have a choice
of who's compiler you can use.  This has  already happend in the Modula
Market, so why not Pascal, C, ect..

   Both enviroments are very good, but I've gotten used to MPW and now I
find it difficult to use anything else, what no shell scripts?  Where
are my shell variables, where are the user defined menus, no make
facility, my god are we working in the stone ages here?


David M. O'Rourke
--
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| dorourke@polyslo | Disclaimer:  All opinions in this message are mine, but  |
|                  |              if you like them they can be yours too.     |
|                  |              Besides I'm just a student so what do I     |
|                  |              know!                                       |
|-----------------------------------------------------------------------------|
|    When you have to place a disclaimer in your mail you know it's a sign    |
| that there are TOO many Lawyer's.                                           |
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


------------------------------

From: [e-mail] (David M. O'Rourke)
Subject: Re: Writing PICT files
Date: 19 May 88 04:07:27 GMT
Organization: Cal Poly State University -- San Luis Obispo

In article <[e-mail]> [e-mail]
(William R. Pearson) writes:
>       Given a PicHandle, how does one write a PICT file that can be
>edited by a drawing program?  Pointers to appropriate references will be
>appreciated.

   Heres some pascal style code that might help.  This assumes that
you've already generated the picture and have a valid handle to play
with.

function WritePicture (thePictHandle : PicHandle): BOOLEAN;
  var
    FileErr      : OSErr;
    PictLength   : LONGINT;
    FileRefNum   : INTEGER;
    FileRecord   : SFReply;
    PutFilePoint : Point;
    FileFndrInfo : FInfo;
  begin
    {First we need to get a File Name from the user.  To do this we're
going}
    {to use the standard file package from Volume I of inside Mac.  I
have
     put constants in some position that should be variables, please
extend
     this code to calculate screen position, prompt, ect. at run time,
for
     now this illustrates the concept}

    PutFilePoint.v := 30;
    PutFilePoint.h := 50;  {This value really should be calculated based
on
                            the screen size from ScreenBits.bounds}
    SFPutFile(PutFilePoint, 'Please type a file Name', 'PictFile.pict',
              nil, FileRecord);

    {Now that we have an output file name, and record lets use it}
    FileErr := GetFInfo(FileRecord.fName, FileRecord.vRefNum,
                        FileFndrInfo);
    if FileErr = fnfErr then
      begin
        FileErr := Create(FileRecord.fName, FileRecord.vRefNum,
YourCreator,
                          'PICT');
        if FileErr <> noErr then
          begin
            Do_Something_To_Report_the_problem;
          end;  {if FileErr <> noErr}
       end {if FileErr = fnfErr}
     else
       begin
         FileFndrInfo.Type := 'PICT';
         FileErr := SetFInfo(FileRecord.fName, FileRecord.vRefNum,
                             FileFndrInfo);
       end; {else}

     FileErr := FSOpen(FileRecord.fName, FileRecord.vRefNum,
FileRefNum);
        if FileErr <> noErr then
          begin
            Do_Something_To_Report_the_problem;
          end;  {if FileErr <> noErr}

     FileErr := SetFPos (FileRefNum, fsFromStart, 0);
        if FileErr <> noErr then
          begin
            Do_Something_To_Report_the_problem;
          end;  {if FileErr <> noErr}

     PictLength := GetHandleSize(Handle(thePictHandle));

     HLock(Handle(thePictHandle));
     FileErr := FSWrite(FileRefNum, PictLength, @thePictHandle^^);
        if FileErr <> noErr then
          begin
            Do_Something_To_Report_the_problem;
          end;  {if FileErr <> noErr}

     FileErr := SetEOF(FileRefNum, PictLength);
        if FileErr <> noErr then
          begin
            Do_Something_To_Report_the_problem;
          end;  {if FileErr <> noErr}

     HUnLock(Handle(thePictHandle));

     FileErr := FSClose(FileRefNum);
        if FileErr <> noErr then
          begin
            Do_Something_To_Report_the_problem;
          end;  {if FileErr <> noErr}

     if FileErr = noErr then
       WritePicture := True
     else
       WritePicture := False;

     {Set the value of the function to indicate success/falure}
   end; {WritePicture}


  This codes isn't perfect, but it should give you a rough idea about
how to approach the problem.  As far as readings go I'd recommend that
you check chapter 20 of vol I, chap. 5 of volume 1, and chap. 4 in vol
II, those should help matter some what.
   Hope it helps


David M. O'Rourke
--
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| dorourke@polyslo | Disclaimer:  All opinions in this message are mine, but  |
|                  |              if you like them they can be yours too.     |
|                  |              Besides I'm just a student so what do I     |
|                  |              know!                                       |
|-----------------------------------------------------------------------------|
|    When you have to place a disclaimer in your mail you know it's a sign    |
| that there are TOO many Lawyer's.                                           |
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


------------------------------

From: [e-mail] (Marty Kent)
Subject: Anyone using pcl (clos) under Allegro Common Lisp?
Date: 19 May 88 12:44:08 GMT
Organization: School of Education, UC-Berkeley

Is anyone out there doing anything with pcl (CLOS) under Allegro common
lisp? I've recently gotten the sources from parcvax, and I'm interested
in the possibility of rewriting a bunch of code I've done in Object
Lisp, in pcl. (Got that?)

One reason I'd like to do this is that I'd expect to get a substantial
speed increase. The Allegro documentation says that Object Lisp is not
to be expected to run at high speed, but what about the implementation
of pcl? Since it's still in some kind of early state of development,
what kind of performance can one expect from the current version? I'd be
very interested to hear from anyone who's actually done any measured
comparisons between the two systems.

Another factor possibly in pcl's favor is that it's supposedly on the
way to becoming a standard, while Object Lisp's future seems to be less
than rosy... Do you feel pcl is in fact emerging as a standard like
common lisp (I mean widely accepted like common lisp, not necessarily
funky like common lisp :-) or are there other lisp object extension
systems clearly "in the running?"

I'd be interested in hearing from anyone with thoughtful stuff to say
about these things.

Marty Kent      Sixth Sense Research and Development
                415/642 0288    415/548 9129
                [e-mail]
                {uwvax, decvax, inhp4}!ucbvax!mkent%dewey.soe.berkeley.edu Kent'
s
heuristic: Look for it first where you'd most like to find it.


------------------------------

From: [e-mail] (Marty Kent)
Subject: "Asynchronous" processing in Allegro Common Lisp?
Date: 19 May 88 12:47:31 GMT
Organization: School of Education, UC-Berkeley


   Are there any functions in Allegro that are subject to return before
all their work has actually been completed? For instance, I can imagine
the possibility that a function might queue something to be handled in a
Mac operating system queue, and then return immediately afterward,
without any guarantee that the os had already handled that processing.

   I'm curious about whether it's possible for (window-close) to return
while the image of the window is still visible on the screen. Does
anyone *know*?

Marty Kent      Sixth Sense Research and Development
                415/642 0288    415/548 9129
                [e-mail]
                {uwvax, decvax, inhp4}!ucbvax!mkent%dewey.soe.berkeley.edu Kent'
s
heuristic: Look for it first where you'd most like to find it.


------------------------------

From: [e-mail] (Chris McConnell)
Subject: Re: Anyone using pcl (clos) under Allegro Common Lisp?
Date: 19 May 88 17:43:22 GMT
Organization: Advanced Decision Systems, Mt. View, CA [phone]


The current version of PCL is implementing most of the Common Lisp
Object System (CLOS).  This will be the Object Oriented Programming
standard for Common Lisp.  I believe it will be officially approved
sometime in June.

PCL is fairly portable.  I plan to bring it up in Allegro in the next
month.  If you accept the most generic implementation, it should already
run in Allegro.  (In fact, it may even have optimizations already since
Allegro is really Franz and it already runs in Franz.) There are
numerous ways to get it to run faster on a given implementation, but
modifying the PCL code requires a very good knowledge of Lisp.  I have
done a lot of it fixing bugs and adding features, and I can tell you
that it is no picnic.

I ran some benchmarks a while ago on a Symbolics and a Sun running
Lucid.  The speed was better than I thought it would be for an early and
portable implementation.  Creation is slow, but execution speed of
generic functions is very good.  (Some of this is due to the caching
mechanism that makes more recent methods faster.)  We developed an image
understanding environment using it, so the speed can't be too slow!

I have been working in CLOS for a year (> 25,000 lines), and I have to
say that even in its presently incomplete state that I love it.  I have
worked extensively in Flavors, an in house system called SOPE and some
in Smalltalk.  CLOS is far and away my favorite.  Multiple specializers
are great, especially on normal Lisp objects.  The spec takes great
pains to make all of the hooks that are needed available and public
while still allowing implementations to do all of the things that are
required to make things run fast.


------------------------------

From: [e-mail] (Jeffrey A. Sullivan)
Subject: Re: Anyone using pcl (clos) under Allegro Common Lisp?
Date: 19 May 88 19:11:29 GMT
Organization: Decision Systems Lab., Univ. of Pittsburgh, PA.

In article <[e-mail]>, [e-mail]
(Marty Kent) writes:
> Another factor possibly in pcl's favor is that it's supposedly on the way to
Well, PCL is migrating toward a full implementaiton of CLOS (the Common
Lisp Object System), but it aint QUITE there yet.  It is, however, quite
usable. And very powerful.  I know that there have been some
optimizations in it (I read the code), but there are no broad-based
ones, and I can not vouch for its speed.  I am using PCL entirely in a
project of mine, and haven't had any complaints, but I am not concerned
with efficiency at this time.

CLOS _is_ the standard OOPS for CL, so using it is no bad idea.  There
is no doubt that CLOS (of which PCL is slowly implemeting) is the only
OOPS officially supported by CL, so don't worry.

There is, however, a LOT of code to CLOS/PCL, and it takes quite a tot
of memory, while OL doesn't.  Note that OL's future is not so bad, Coral
will almost definitely implement a copy of OL in CLOS (it's not too
hard...) just for compatibility's sake.

--
..........................................................................
Jeffrey Sullivan                          | University of Pittsburgh
[e-mail]              | Intelligent Systems Studies Program
[e-mail], [e-mail] | Graduate Student


------------------------------

From: [e-mail] (Jim Matthews)
Subject: Re: suppress display of password entry
Date: 19 May 88 14:17:23 GMT
Organization: Dartmouth College, Hanover, NH

In article <[e-mail]> [e-mail] (Wade Blomgren)
writes:
>
>What is the best (easiest) way to allow entry of a password on the screen
>while suppressing the display of the actual characters in the
>edittext item?

It actually isn't very difficult to intercept the key events and keep  a
hidden copy of the password string.  It isn't necessary to remember any
context since you have access to the TextEdit record, and it tells you
what the current selection is.  The following routine is a filter for a
name/password dialog box.  It displays bullets (ala AppleShare) and
stores the real password in a global string, pwStr.  It also handles
hitting return or enter.

{ signonFilter -- dialog filter for doSignon, hides password } FUNCTION
signonFilter (dp : DialogPtr;
            VAR theEvent : EventRecord;
            VAR itemHit : integer) : boolean;
    CONST
        nameItem = 3;
        passwordItem = 4;
        bs = $08;
        tab = $09;
        cr = $0D;
        enter = $03;
        larrow = $1C;
        rarrow = $1D;
        uparrow = $1E;
        downarrow = $1F;
    VAR
        dpeek : DialogPeek;
        theChar : char;
        theStr : Str255;
        selStart, selEnd : integer;
        h : Handle;
        itemType : integer;
        box : Rect; BEGIN
    signonFilter := false;
    dpeek := DialogPeek(dp);
    IF ((theEvent.what = keydown) OR (theEvent.what = autoKey)) THEN
        IF (dpeek^.editField = passwordItem - 1) THEN
        BEGIN
            theChar := char(BitAnd(theEvent.message, charCodeMask));
            selStart := dpeek^.textH^^.selStart;
            selEnd := dpeek^.textH^^.selEnd;
            CASE ord(theChar) OF
                bs :                { Backspace }
                    BEGIN
                        IF selEnd = selStart THEN  { back over a
character }
                        BEGIN
                            IF selStart > 0 THEN
                                pwStr := concat(copy(pwStr,1, selStart -
1),
                                                  copy(pwStr, selStart +
1,
                                                   length(pwStr) -
selStart));
                        END
                        ELSE            { delete the selection }
                            pwStr := concat(copy(pwStr, 1, selStart),
                             copy(pwStr, selEnd + 1,
                                   length(pwStr) - selEnd));
                    END;
                cr, enter :     { Return or Enter -- treat as "OK }
                    BEGIN
                        itemHit := ok;
                        signonFilter := true;
                    END; { cr, enter }
                tab, uparrow, downarrow, rarrow, larrow :
                    ;        { just pass on tabs & arrows }
                OTHERWISE   { "normal" character }
                    BEGIN        { remember character, insert a bullet }
                        pwStr := concat(copy(pwStr, 1, selStart),
                         theChar,
                         copy(pwStr, selEnd + 1, length(pwStr) -
selEnd));
                        theEvent.message :=
                         BitAnd(theEvent.message, $FFFFFF00) + ord('*');
                    END; { normal character }
            END; { case ord(theChar) of }
        END { in password field }
        ELSE     { not in password field -- still check for cr, enter }
            CASE BitAnd(theEvent.message, charCodeMask) OF
                cr, enter :
                    BEGIN
                        itemHit := ok;
                        signonFilter := true;
                    END; { cr, enter }
                OTHERWISE
                    ;
            END; { case BitAnd } END; { signonFilter }

The bullet is replaced with an asterisk, since it's an 8-bit character.

Hope this helps,
--
Jim Matthews
Software Development
[e-mail]


------------------------------

From: [e-mail] (Pierce T. Wetter)
Subject: Re: Utilities for RGB to 8-Bit
Date: 19 May 88 19:53:34 GMT
Organization: California Institute of Technology

     Sure, get one pixel at a time from your unix file, then SetRGBColor
to
  red*256, green*256, blue*256, then SetPixel(x,y). This saves
programmer time
  at the expense of user time.

     You might also want to do dithering, best simple dither is 50% of
one
  color + 50% of another color, but I don't know any dithering
algorithms off  the top of my head.

Pierce WEtter
--
----------------------------------------------------------------
[e-mail]     Race For Space Grand Prize Winner.
-----------------------------------------------------------------
   Useless Advice #986: Never sit on a Tack.

------------------------------

End of Usenet Mac Digest
************************

ACTION>